Deploy preview for kaibu ready!

Built with commit 8cb5495

https://deploy-preview-50--kaibu.netlify.app

@oeway awesome!

The main issue for now is the coordinate system is not in sync with openlayers after the upgrade, it appears to be the origin position issue (the y axis are reversed). @thewtex Any tips for fixing this?

Does this provide the desired behavior?
Kitware/itk-vtk-viewer@b658e38

@thewtex The new option xyLowerLeft fixes the issue, thank you!

I have another minor issue about the UI, the part for contrast stretching is currently collapsed by default, how make it open by default?

I have another minor issue about the UI, the part for contrast stretching is currently collapsed by default, how make it open by default?

This should not be the case, hopefully it is addressed by Kitware/itk-vtk-viewer#364 . If it is still persistent, would could add an API function to programmatically select a layer.

@thewtex
It's wired that it still doesn't work for me, I still go the red color map after upgrading to "itk-vtk-viewer": "^11.1.1".

Basically, made a multiScaleImage by first read the jpg image from url with:

function convertImageUrl2Itk(url) {
  return new Promise(resolve => {
    const canvas = document.createElement("canvas");

    const image = new Image();
    image.onload = function() {
      canvas.width = image.width;
      canvas.height = image.height;
      const ctx = canvas.getContext("2d");
      // flip the image to make it upside down
      ctx.translate(0, image.height);
      ctx.scale(1, -1);
      ctx.drawImage(image, 0, 0, image.width, image.height);
      const imageData = ctx.getImageData(0, 0, image.width, image.height);
      resolve({
        imageType: {
          dimension: 2,
          pixelType: 1,
          componentType: "uint8_t",
          components: 4
        },
        name: "test image",
        origin: [0, 0],
        spacing: [1, 1],
        direction: { data: [1, 0, 0, 1] },
        size: [image.width, image.height],
        data: new Uint8Array(imageData.data.buffer)
      });
    };
    image.crossOrigin = "Anonymous";
    image.src = url;
  });
}

Then convert the itkImage with itkVtkViewer.utils.toMultiscaleChunkedImage, and I checked the properties of the image, I got:

imageType:
  componentType: "uint8_t"
  components: 4
  dimension: 2
  pixelType: 1

It should work according to here, however, I still go the reddish color map.

@oeway how about setting pixelType to 3 for RGBA?

@oeway how about setting pixelType to 3 for RGBA?

What should we change for the component type and number then? I tried this but failed:

imageType: {
  dimension: 2,
  pixelType: 3,
  componentType: "uint8_t",
  components: 4
},

@thewtex

imageType: {
  dimension: 2,
  pixelType: 3,
  componentType: "uint8_t",
  components: 4
},

@oeway this looks correct.

@thewtex For some reason, I still get red image with the latest version 11.1.1, if I switch to pixelType= 3, then the entire image is heavily saturated.

@oeway with this patch, the result is:

@thewtex Yes, it works now! One last request for this PR, it seems the the contrast stretching panel is still collapsed by default, but I remembered you already fixed it?

@thewtex Any idea on why it's still red when using pixelType 14 and itk-vtk-viewer v11.1.4?

@thewtex Any idea on why it's still red when using pixelType 14 and itk-vtk-viewer v11.1.4?

I am digging into this. I will get WASM debugging going in the process.

@thewtex Great! Please keep me posted, I would like to merge this issue after you fixed it!

@thewtex After upgrading to 11.2.0, I got 404 error with this link: https://unpkg.com/[email protected]/Pipelines/DownsampleWasm.js.

@thewtex After upgrading to 11.2.0, I got 404 error with this link: https://unpkg.com/[email protected]/Pipelines/DownsampleWasm.js.

@oeway thanks for the note. This branch should address this: Kitware/itk-vtk-viewer#379 , but we have to merge / publish before it can be tested.

HI @thewtex Thanks for the fix, I can now load it, the independent components are shown, the collapse bug also being fixed!

However, when I use pixelType=14, I got this gray image, I guess I will need to call setImagePiecewiseFunctionGaussians ? Could you give an example on how should I configure it such that it will look the same as when I have pixelType=3? It might be good to set that as the default behavior, no?

Hi again @thewtex I am trying to set the Color map with the following lines:

      viewer.setImageColorMap('BkRd', 0)
      viewer.setImageColorMap('BkGn', 1)
      viewer.setImageColorMap('BkBu', 2)

But this failed because this error:

itkVtkViewerCDN.js?ba90:2 Uncaught (in promise) TypeError: Cannot read property '0' of undefined
    at Object.l.mark.l.wrap.v.setImageColorMap (itkVtkViewerCDN.js?ba90:2)
    at _callee3$ (ItkVtkLayer.vue?15c1:329)
    at tryCatch (vue-form-json.common.js?0df0:3273)
    at Generator.invoke [as _invoke] (vue-form-json.common.js?0df0:3503)
    at Generator.eval [as next] (vue-form-json.common.js?0df0:3328)
    at asyncGeneratorStep (asyncToGenerator.js?1da1:3)
    at _next (asyncToGenerator.js?1da1:25)

I try to dig into it, but found I could not do npm link and test it with my local itk-vtk-viewer repo anymore because of an error:

itkVtkViewerCDN.js?ba90:2 GET https://unpkg.com/[email protected]/dist/itk/WebWorkers/Pipeline.worker.js 404
...
itkVtkViewerCDN.js?ba90:2 Uncaught (in promise) Error: Request failed with status code 404
    at e.exports (itkVtkViewerCDN.js?ba90:2)
    at e.exports (itkVtkViewerCDN.js?ba90:2)
    at XMLHttpRequest.f.onreadystatechange (itkVtkViewerCDN.js?ba90:2)

No idea how to proceed now, maybe you can take a look?

I thought I might found something, in the case of RGBA, we have 4 components, but we only handle the case of 3: https://github.com/Kitware/itk-vtk-viewer/blob/6b51d86ba26592471ff32b4e6bc31a56d56b3d93/src/UI/Layers/createLayersUIMachine.js#L165-L177

And also, for the alpha channel, is there a color map that for the transparency mask? Or we simply ignore it?

Hi @oeway :-)

When I try to npm link itk-vtk-viewer with this current branch, I am receiving a different error:

error  in ../itk-vtk-viewer/dist/itkVtkViewerCDN.js

Module Error (from ./node_modules/eslint-loader/index.js):

/home/matt/src/itk-vtk-viewer/dist/itkVtkViewerCDN.js
  19:19  error  Parsing error: Unexpected token )

✖ 1 problem (1 error, 0 warnings)


 @ ./node_modules/cache-loader/dist/cjs.js??ref--12-0!./node_modules/babel-loader/lib!./node_modules/cache-loader/dist/cjs.js??ref--0-0!./node_modules/vue-loader/lib??vue-loader-options!./src/components/layers/ItkVtkLayer.vue?vue&type=script&lang=js& 71:0-68 153:18-36 269:30-48 297:34-52 347:23-48 403:23-41 412:23-48 577:14-32
 @ ./src/components/layers/ItkVtkLayer.vue?vue&type=script&lang=js&
 @ ./src/components/layers/ItkVtkLayer.vue
 @ ./src/components/layers/index.js
 @ ./node_modules/cache-loader/dist/cjs.js??ref--12-0!./node_modules/babel-loader/lib!./node_modules/cache-loader/dist/cjs.js??ref--0-0!./node_modules/vue-loader/lib??vue-loader-options!./src/components/ImageViewer.vue?vue&type=script&lang=js&
 @ ./src/components/ImageViewer.vue?vue&type=script&lang=js&
 @ ./src/components/ImageViewer.vue
 @ ./src/router/index.js
 @ ./src/main.js
 @ multi (webpack)-dev-server/client?http://10.10.10.247:8080&sockPath=/sockjs-node (webpack)/hot/dev-server.js ./src/main.js

Does this ring a bell?

I thought I might found something, in the case of RGBA, we have 4 components, but we only handle the case of 3: https://github.com/Kitware/itk-vtk-viewer/blob/6b51d86ba26592471ff32b4e6bc31a56d56b3d93/src/UI/Layers/createLayersUIMachine.js#L165-L177

And also, for the alpha channel, is there a color map that for the transparency mask? Or we simply ignore it?

Yes, 4 is not in the switch statement, but for the alpha channel, the intention is to use Grayscale, which should come from the default value.

When I try to npm link itk-vtk-viewer with this current branch, I am receiving a different error:

Hi, I just tried and I do get this error, I saw it before. And I can fix it by change the `"ecmaVersion" from 6 to 11. However, when I switch back to 6 again, I cannot reproduce it. Could you try to pull from my branch and test it again? Thanks!